新しいopswitchのアーキテクチャ ~ジョブ編~

#opswitch

#AWS Step Functions

Gre212

2023.03.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

opswitch は、2023年1月30日にリニューアルを行いました。UIやバックエンド構成など全体を見直し、使いやすくなりパフォーマンスも改善されています。今回はその新しくなった opswitch を支えるアーキテクチャを紹介していきます。

opswitch とは

opswitch は、AWS運用におけるインスタンスの起動・停止やバックアップの作成などを、ブラウザから自動で実行することができるAWS運用サポートツールです。今回のリニューアルでアーキテクチャを一新し、新機能も追加されています。

以下、リニューアル前のopswitchを旧opswitch、リニューアル後のopswitchを新opswitchとして説明します。

新機能については、以下の記事で詳しく紹介しているのでぜひご覧ください。

旧opswitch の構成

旧opswitch はWeb、Worker、Schedulerの大きく3つのシステムで構成されています。リニューアルの説明に入る前に、それぞれの役割について簡単に紹介します。

旧opswitch は、Apache Airflow をもとに開発されています。 WorkerやSchedulerという概念は、このAirflowのアーキテクチャ構成に由来するものです。

大まかな役割としては以下の通りです。

Web : ユーザー向けのUIを提供。自動化したい作業をDBに登録する。
Scheduler : 実行対象になった作業（ジョブ）の情報をWorkerに情報を渡す。
Worker : Schedulerから受け取ったジョブを実行する。

今回の記事では、ジョブの実行に関わっている Worker、Scheduler の構成を紹介します。

Web側については、こちらの記事で紹介しています。

リニューアルのきっかけ

まず、opswitch は2019年にリリースされ、約4年が経過しました。リリース当初は問題がなかったアーキテクチャも、利用者が増えるにつれてパフォーマンスやコストなどの課題が出てきました。

まずは旧opswitchのアーキテクチャの構成と、その課題について説明します。

旧opswitchの構成と課題

旧opswitchの構成は、以下のような形でした

Worker、Scheduler共にECS on EC2上で稼働しています。

SchedulerはS3とRDSに保管されているジョブ情報（DAG）を追跡し、実行対象となったジョブ情報をWorkerに渡します。
Workerは受け取ったジョブの情報をもとに、処理を実行します。

この構成では、ジョブが増えるにつれてそれぞれ以下のような課題が見えてきました。

Scheduler : 多くのDAGファイルを処理するため、ジョブが増えるとスケールアップする必要がある。
Worker : 同時実行数に上限があり、ジョブが増えると実行待ちの時間が発生することがある。同時実行数を増やすためにはスケールアウトの必要がある。

ただ、これらの問題は「朝の9時」や「夜18時」などジョブの実行が集中する時間帯にのみ問題が発生しており、ピーク時以外の時間帯の負荷はそれほど高くありませんでした。そのためスケールアウト/スケールアップの費用対効果が悪くなっていました。

また、上記のような課題に対応するために処理も複雑化しており、開発コストも嵩んでいました。

これらの理由から、アーキテクチャのリニューアルが決まりました。

リニューアル後

今回のリニューアルで、解決しなければいけなかった課題は以下の3つの項目です。

課題1 : 無駄な費用を削減し、全体の費用を抑える。
課題2 : ジョブの数が増えても、柔軟にスケールできる。
課題3 : マネージドサービスを活用し、シンプルな構成にする事で開発コストを抑える。

これらの要件を満たすためには、今まで採用していたAirflowではopswitchのケースと相性が悪かったこともあり、Airflowを脱却し全てのシステムを作り直すことになりました。

構成の説明

最終的に、上記のようなアーキテクチャ構成となりました。全体として、Step FunctionsとLambdaを主軸にした構成になっています。

流れとしては、以下のフローで処理が進みます。

実行対象の監視 : Schedulerステートマシン
ジョブの処理 : Jobステートマシン
タスクの実行 : Taskステートマシン

それぞれ解説します。

実行対象の監視 : Schedulerステートマシン

実行対象のジョブが無いかを確認する部分です。旧opswitchのSchedulerに当たります。 Lambdaから実行対象の確認を行い、ジョブが見つかったらSNSを通じてSQSに登録します。

ジョブの処理 : Jobステートマシン

ジョブを処理する部分です。SQSへの登録をトリガーに、Lambdaを通じてステートマシンが起動します。ジョブに登録されたタスクは、更にTaskステートマシンに処理を渡します。

タスクの実行 : Taskステートマシン

Jobステートマシンから受け取った処理を実行します。

構成のメリット

ジョブ1つ1つに対してステートマシンが起動する形に変わったことで、ジョブを実行するためにインスタンスを調達する必要がなくなりました。そのため、EC2スケールアウトによって発生していた無駄なコストを削減することができました。

また、StepFunctionsに一連の処理がまとまったことで、処理の流れが追いやすく、開発やログの調査なども行いやすくなりました。

解決された課題

改めて、課題とその解決策を整理してみます。

課題1 : 無駄な費用を削減し、全体の費用を抑える。
従来EC2で動いていた2つのシステムを、サーバーレス環境に移行しました。これにより呼び出しベースでの課金となり、ピーク時以外に発生していた無駄な費用を抑制することができました。

課題2 : ジョブの数が増えても、柔軟にスケールできる。
StepFunctionsやLambdaなど、マネージドサービスの自動スケールを活用する構成に変更しました。これにより、ピーク時でもパフォーマンスの低下や実行待ちをほとんど気にすることなく、ジョブを処理することができるようになりました。

課題3 : マネージドサービスを活用し、シンプルな構成にする事で開発コストを抑える。
ソースコードはほぼ全てLambdaで実行され、周辺処理はStepFunctionsやSQSなど全てAWSのマネージドサービスを最大限活用しての構成に変更しました。これにより、シンプルかつ見通しの良い構成になったことで開発コストを抑えることができました。また、フレームワークにも依存しなくなったため、より柔軟に機能開発ができるようになりました。